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The  Departmentof  Defense  (DoD)  could  achieve  substantially  higheracquisition 
cost  savings  by  following  the  lead  of  industry  in  applying  systems  engineering 
theory  to  organizational  structure,  to  develop  an  enterprise  architecture  for 
DoD  acquisition. 


The  Department  of  Defense  has  made 
great  strides  within  the  past  five 
years  in  moving  defense  acquisition 
processes  toward  successful  business 
practices.  Despite  the  undeniable  suc¬ 
cesses  achieved,  acquisition  reform  has 
the  potential  to  achieve  substantially  more 
costs  savings  than  have  to  date  been  real¬ 
ized.  These  potential  savings  must  be 
achieved  if  the  services  are  to  be  able  to 
modernize  for  tomorrow’s  operational 
demands. 

Much  of  the  equipment  used  by  our 
warfighters  is  old,  and  gets  older  each  day. 
The  costs  associated  with  supporting  these 
systems  are  increasing  with  time. 
Although  it  appears  that  continued 
reductions  in  defense  procurement 
budgets  may  level  off  and  may  actually 
increase  in  the  coming  years,  more  pro¬ 
curement  dollars  will  be  needed  to  meet 
the  needs  of  the  services.  Jacques  Gansler, 
Under  Secretary  of  Defense  for  Acquisi¬ 
tion,  Technology,  and  Logistics  (USD 


[AT&L]),  has  continually  spoken  of  the 
need  to  generate  the  dollars  necessary  to 
modernize  forces  while  continuing  to  meet 
the  operations  and  maintenance  demands 
of  high  operational  tempos. 

Where  will  these  funds  come  from?  The 
premise  of  this  article  is  that  DoD  could 
achieve  substantially  higher  acquisition 
cost  savings  by  following  the  lead  of 
industry  in  developing  an  enterprise 
architecture  for  DoD  acquisition.  Com¬ 
mercial  corporations  have  discovered  that 
efficient  business  processes  must  be 
carried  out  within  streamlined,  seamless 
organizational  structures.  To  achieve 
higher  cost  savings,  DoD  must  reengineer 
its  organizational  structure.  This  will 
require  a  change  in  focus  from  optimiz¬ 
ing  individual  departments  and  functions 
toward  a  top-down  approach  that  focuses 
on  optimizing  the  DoD  acquisition  system 
at  the  highest  (enterprise)  level. 

The  proposed  solution  is  the  develop¬ 
ment  of  an  enterprise  architecture  for  DoD 
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acquisition.  Enterprise  architecting  is  the 
application  of  proven  systems  engineer¬ 
ing  principles  for  integrating  complex 
systems  applied  toward  integrating 
complex  organizations.  Most  large  corpo¬ 
rations  have  realized  that  they  cannot  be 
effective  and  survive  the  commercial 
marketplace  unless  they  develop  an  archi¬ 
tecture  for  their  organization  that  provides 

a  seamless  in¬ 
tegration  be¬ 
tween  different 
elements  of  the 
corporation. 
The  larger  and 
more  complex 
the  organiza¬ 
tion,  the  more 
critical  this  is.  When  subsystems  of  either 
a  physical  or  organizational  system  are  not 
designed  to  be  interoperable  with  seam¬ 
less  operation  across  the  interface,  an 
“architectural  mismatch”  occurs  and  poor 
system  level  performance  results. 

Enterprise  Architecture 


What  is  an  enterprise  architecture?  By 
the  definition  of  John  Zachman,  “Archi¬ 
tecture  is  that  set  of  design  artifacts,  or 
descriptive  representations,  that  are 
relevant  for  describing  an  object  such  that 
it  can  be  produced  to  requirements  (qual¬ 
ity)  as  well  as  maintained  over  the  period 
of  its  useful  life  (change)”  (Zachman, 
1991,  p.  4).  An  enterprise  architecture  is 
developed  by  applying  this  concept  to  the 
organizational,  or  enterprise,  level  of  a 
company  or  organization.  This  can  be 
accomplished  by  applying  many  of  the 
tools  of  systems  engineering  to  the 
engineering  of  an  organizational  structure. 


The  discipline  of  systems  engineering 
came  about  as  industry  began  to  develop 
complex  systems  and  products.  Engineers 
realized  that  having  specialists  first  design 
and  build  optimized  components  and  then 
attempt  to  integrate  them  resulted  in 
poorly  performing  systems.  This  method 
was  also  time-consuming  and  expensive 
as  many  components  required  extensive 
redesign  and  rework  to  get  them  to  be 
interoperable.  Furthermore,  the  voice  of 
the  customer  was  often  lost  in  the  pursuit 
of  optimum  performance  at  the  subsystem 
level. 

Systems  engineering  was  developed  as 
a  process  to  design  systems  from  the  top 
down.  The  system  level  architecture  is 
defined  first.  Subsystems  and  components 
are  then  designed  to  support  the  system 
requirements  and  to  be  interoperable  with 
other  components  and  subsystems.  In 
many  cases,  this  requires  that  the  indi¬ 
vidual  subsystems  or  components  be 
suboptimized.  However,  the  result  is  a 
better  overall  system  that  can  be  developed 
faster  and  at  a  lower  cost. 

Many  large,  complex  coiporations  have 
realized  that  this  same  principle  applies 
to  the  architecture  of  an  organization. 
Most  corporations  have  traditionally  been 
organized  around  functional  areas  such  as 
marketing,  accounting,  engineering,  and 
public  relations.  In  most  cases,  these  func¬ 
tional  departments  were  designed  to  be  the 
most  efficient  at  the  functional  task  they 
performed.  This  has  led  to  efficient 
departments  that  combine  to  produce 
dysfunctional  organizations. 

The  epitome  of  this  type  of  structure  is 
satirized  in  the  cartoon  strip  “Dilbert.” 
Dilbert  attempts  to  do  his  job  amidst 
insurmountable  trials  and  tribulations: 
Research  won’t  give  him  the  product 


"  Systems 
engineering  was 
developed  as  a 
process  to  design 
systems  from  the 
top  down." 
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requirements,  accounting  reduces  his 
budget,  his  boss  tells  him  to  get  started 
without  the  requirements  so  he  looks  busy 
to  upper  management,  and  on  and  on. 
Why  is  the  “Dilbert”  cartoon  strip  so 
popular?  Probably  because  so  many  of  us 
can  relate  to  these  issues  in  our  daily  jobs. 

Major  commercial  companies  are 
realizing  that  this  type  of  functional 
behavior  is  inefficient  and  wasteful,  and 
that  it  threatens  their  future  survival  in 
the  global  marketplace.  They  are  devel¬ 
oping  enterprise  architectures  to  inte¬ 
grate  their  organizations  and  provide  a 
clear  vision  of  where  they  are  headed  in 
the  future. 

A  good  analogy  of  the  process  involved 
in  developing  an  enterprise  architecture 
is  a  city  planning  commission.  These  com¬ 
missions  make  zoning  laws,  review  build¬ 
ing  plans  and  permits,  manage  building 
codes,  and  grant  deviations  on  a  case-by¬ 
case  basis.  They  monitor  demographics, 
economics,  changes  in  technology,  and 
attitudes  in  the  community.  For  a  city  to 
operate  effectively,  the  commission  must 
balance  the  conflicting  priorities  and  goals 
of  diverse  groups  such  as  its  citizens, 
builders,  businesses,  and  employees. 
Interfaces  between  these  conflicting 
groups  must  also  be  managed  so  that  the 
best  interests  of  the  city  as  a  system  are 
achieved.  The  process  must  also  be 
responsive  to  change. 

Why  does  enterprise  architecting  play 
such  a  large  role  in  commercial  compa¬ 
nies?  In  1967, 40  to  50  percent  of  the  cost 
of  a  product  was  direct  (touch)  labor. 
Today  that  percentage  is  as  low  as  15 
percent.  At  the  same  time,  between  20  and 
50  percent  of  all  labor  cost  in  the  United 
States  is  now  dedicated  to  gathering, 
storage,  retrieval,  reconciliation,  and 


reporting  of  information  used  to  run  the 
company  (Zachman,  1997,  pp.  8-10). 

Because  of  the  functional  organization 
of  most  companies,  this  task  is  being 
accomplished  with  horrible  inefficiencies. 
Larry  English  of  Information  International 
has  observed  that  70  percent  of  computer 
printouts  were  used  to  enter  the  same  data 
into  a  different  database.  Bill  Smith  of 
William  G.  Smith  Associates  has  observed 
that  70  percent  of  the  lines  of  code  used 
by  a  company  are  doing  nothing  but  mov¬ 
ing  data  from  system  to  system  and  40 
percent  of  machine  cycles  are  expended 
moving  data  that  produces  no  useful  work. 
At  a  cost  of  $  1  to  $4  per  line  of  code  for 
Y2K  correction 
and  testing,  the 
price  tag  to  en¬ 
sure  that  these 
programs  are 
now  working  is 
in  the  hundreds 
of  billions  of 
dollars.  Statisti¬ 
cally,  the  aver¬ 
age  data  fact  is 
stored  10.8  times  within  a  company 
information  structure  (Zachman,  1997,  pp. 
8-10).  Since  DoD  is  heavily  engaged  in 
generating  and  using  information  (rather 
than  producing  physical  products),  our 
percentages  are  likely  worse  than  our 
commercial  counteiparts. 

Figures  such  as  these  arc  bound  to  cap¬ 
ture  the  attention  of  any  chief  executive 
officer.  As  Doug  Erickson  remarked, 
“Where  do  you  think  management  is 
going  to  get  any  more  major  chunks  of 
cost  reduction?  It  looks  to  me  like  these 
enormous  costs  of  architectural  discon¬ 
tinuities  and  redundancies  are  now  the 
Tow  hanging  fruit’  just  waiting  to  be 


"A  good  analogy 
of  the  process 
involved  in 
developing  an 
enterprise 
architecture  is  a 
city  planning 
commission." 
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picked”  (Zachman,  1997,  p.  10).  The  best 
part  of  the  enteiprise  architecture  is  that 
up-front  investment  is  minimal  compared 
to  other  cost-saving  initiatives,  such  as 
automation.  Like  systems  engineering, 
much  of  this  is  just  a  commonsense 
approach  to  doing  business.  The  difficult 
part  will  be  to  smash  down  the  walls  of 
functional  bureaucracy  in  implementing 
these  changes. 

Some  may  argue  that  DoD  is  already 
embarked  on  development  of  an  enteiprise 
architecture  through  implementation  of 
the  “joint  technical  architecture”  and  other 
standardization  initiatives.  It  is  certainly 
true  that  these  initiatives  will  increase 
interoperability  between  functional 
groups  and  organizations  through  im¬ 
proved  design  practices.  However,  this 
effort  falls  far  short  of  the  organizational 
change  required  to  achieve  a  seamless, 
integrated  acquisition  organization.  In 
business  process  reengineering,  the  first 


rule  is  to  optimize  the  process  before 
considering  how  to  automate  it. 

In  enterprise  engineering,  the  issue  is 
not  how  to  make  a  functional  group  more 
efficient,  but  how  to  make  the  organiza¬ 
tion  the  most  efficient.  Instead  of  initia¬ 
tives  to  make  the  travel  section  more  effi¬ 
cient,  the  more  appropriate  question  is,  do 
we  even  need  a  travel  section?  Perhaps  the 
organization  would  be  better  served  by 
placing  travel  service  functions  on  the 
corporate  Intranet  and  having  employees 
make  reservations  and  enter  claims  data 
directly  into  the  system.  Many  current 
acquisition  reform  initiatives  fall  into  the 
category  of  continuing  optimization  of 
functional  areas,  for  example,  in  improved 
contracting  processes  and  improved 
design  practices.  To  achieve  the  full 
potential  of  the  reform  initiative,  we  need 
to  focus  more  on  optimization  at  the 
enterprise  level. 


Table  1.  Zachman  Framework3 


Data 

What 

Function 

How 

Network 

Where 

People 

Who 

Time 

When 

Motivation 

Why 

Scope: 

Planner 

Enterprise 

model: 

Owner 

System 

model: 

Designer 

Technology 

model: 

Builder 

Detailed 

representations: 

Subcontractor 

■  From  Zachman  (1997,  p.  5). 
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Zachman  Framework 


How  can  DoD  develop  an  enterprise 
architecture?  The  most  applicable  ap¬ 
proach  to  enterprise  architectures  for  DoD 
I  have  found  is  the  Zachman  framework 
(Table  1).  John  Zachman  worked  in 
information  systems  for  airframe  manu¬ 
facturing  in  the  early  1970s.  He  developed 
his  enterprise  architecture  when  he  real¬ 
ized  that  the  same  principles  of  systems 
engineering  used  to  engineer  complex 
physical  systems  could  be  applied  to 
engineering  large,  complex  organizations. 
These  important  elements  included  a  clear 
understanding  of  requirements  (goals  of 
the  organization),  seamless  internal  and 
external  interfaces,  prudent  managed  risk 
taking  and  managed  change.  He  developed 
enterprise  engineering  to  accomplish  these 
goals. 

Like  systems  engineering,  enterprise 
engineering  takes  a  top-down  approach 
toward  development  of  the  enterprise 
structure.  DoD  acquisition  would  fit  the 
Zachman  framework  outlined  in  Table  1 
as  follows:  The  Office  of  the  Secretary  of 
Defense  (OSD)  would  be  the  planner  (row 
1).  The  owner  is  the  user  of  the  system 
(row  2).  The  designer  is  the  acquisition 
program  office;  the  builder  is  the  prime 
contractor  of  the  system;  and  the  subcon¬ 
tractors  (row  5)  would  be  subcontractors 
to  the  prime.  The  columns  of  the  Zachman 
framework  then  ask  the  questions:  what, 
how,  where,  who,  when,  and  why.  Filling 
in  the  process  model  in  each  block  and 
then  coordinating  the  interfaces  between 
each  would  provide  the  DoD  acquisition 
architecture,  ensuring  that  all  necessary 
functions  are  addressed,  that  the  functions 
performed  at  each  level  are  defined  and 


understood,  and  defining  the  relationships 
between  levels. 

The  Zachman  framework  provides  an 
excellent  template  for  developing  the 
architecture  of  just  about  anything.  How¬ 
ever,  Zachman  left  out  one  important 
aspect  of  systems  engineering  in  his 
framework  that  would  be  essential  to 
implementing 
an  enterprise  ar- 
chitecture  in 
DoD.  Metrics  is 
an  important  el¬ 
ement  of  track¬ 
ing  progress  to¬ 
ward  achieving 
a  goal  in  any  en¬ 
deavor.  I  would 
therefore  rec¬ 
ommend  that 
one  additional  column  be  added  to  the 
framework  labeled  “progress.”  This  would 
be  the  metric  that  provides  the  key 
measure  of  success  toward  achieving  the 
“what”  of  column  one. 

Applying  the  Zachman 
Framework  to  DoD 


The  Zachman  framework  can  make 
important  contributions  to  acquisition 
reform.  Policy  makers  have  focused  on  the 
what,  how,  where,  and  when  of  what  has 
to  be  done.  They  have  done  little  to  iden¬ 
tify  the  who  or  the  why.  A  key  part  of  the 
systems  engineering  process  is  the 
assignment  of  responsibility  and  metrics 
to  track  progress  toward  achievement  of 
the  goals.  Another  key  is  providing  the 
motivation  of  column  6  to  accomplish  the 
goal. 


"  Like  systems 
engineering, 
enterprise 
engineering  takes 
a  top-down 
approach  toward 
development  of 
the  enterprise 
structure.” 
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In  a  recent  speech  at  the  Defense  Sys¬ 
tems  Management  College,  Vicky  Farrow, 
chief  learning  officer  of  Lucent  Technolo¬ 
gies,  Inc.,  described  how  demanding  good 
personal  performance  on  the  job  was  a 
major  part  of  Lucent’s  rise  from  single¬ 
digit  growth  as  a  part  of  AT&T  to  growth 
rates  in  the  20th  percentile  as  an  indepen¬ 
dent  company  (1999).  She  described  how 
one  employee  was  interviewed  and  asked 
what  her  job  was.  The  woman  explained 
that  her  job  was  to  go  to  job  fairs  and  to 
talk  to  students  about  working  at  Lucent. 
When  asked  how  many  students  to  which 
she  had  spoken  put  in  applications,  she 
said  she  had  no  idea. 

Commercial  industry  has  realized  that 
each  person  must  understand  the  goals  of 
the  company  and  the  part  their  par  ticular 
job  plays  in  the  achievement  of  those 
goals.  To  make  sure  that  these  individual 
linkages  are  defined,  top  companies  pro¬ 
vide  personal  incentives  to  their  workers. 
These  can  take  the  foim  of  bonuses  for 
exceptional  achievement  or  removal  for 
consistent  substandard  performance.  How 
many  DoD  employees  do  we  have  that  are 

like  this  wo¬ 
man?  They  go 
to  work  every 
day  and  per¬ 
form  their  work 
with  little  or  no 
understanding 
of  the  relation¬ 
ship  between 
their  jobs  and 
the  higher  level 
goals  of  sup¬ 
porting  the  warfighter  or  achieving  the 
goals  of  acquisition  reform. 

Establishing  motivation  is  more  diffi¬ 
cult  in  DoD  because  of  many  rules  for 


paying  and  firing  government  employees. 
But  there  are  certainly  some  personal 
motivations  that  could  be  put  in  place 
under  existing  law.  For  example,  to  reduce 
development  time,  OSD  might  assign 
responsibility  to  a  senior  executive  service 
(SES)  employee  to  reduce  the  time  to  get 
through  a  milestone  decision  by  50  per¬ 
cent  over  three  years.  Times  would  be 
measured  and  tracked  and  the  SES’s  bonus 
would  be  directly  tied  to  the  achievement 
of  the  intermediate  goals  for  each  year. 

Developing  an 
Enterprise  Architecture 


An  overview  of  the  enterprise  architec¬ 
ture  planning  process  is  presented  in 
Figure  1.  Following  the  top-down  ap¬ 
proach  of  systems  engineering,  this  pro¬ 
cess  layers  out  four  phases  of  planning  for 
the  implementation  of  an  enterprise 
architecture.  The  four  steps  of  planning 
corresponding  to  the  four  levels  above  ask 
(Spewak,  1993,  p.  14): 

•  Where  do  we  start? 

•  Where  are  we  today? 

•  Where  do  we  want  to  be  in  the  future? 

•  How  do  we  get  there? 

By  answering  these  questions  and 
filling  in  the  Zachman  framework,  the 
outline  of  the  enterprise  architecture  is 
formed. 

Another  area  in  which  the  Zachman 
framework  could  be  applied  to  DoD 
acquisition  is  the  identification  of  the 
interfaces  between  the  various  rows  of  the 


"  Establishing 
motivation  is 
more  difficult  in 
DoD  because  of 
many  rules 
for  paying 
and  firing 
government 
employees." 
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Figure  1.  Components  of  Enterprise  Architecture  Planning 


framework.  Some  progress  has  been  made 
in  improving  the  interface  between  the 
user  and  acquisition  communities.  The 
Joint  Strike  Fighter  program  was  able  to 
integrate  the  user  into  the  program  man¬ 
agement  structure  through  the  integrated 
product  team  (IPT)  process. 

By  assigning  a  group  of  users  to  the 
program  office  staff  to  work  with  the  many 
stakeholders  in  the  Air  Force.  Navy,  and 
Marine  Coips,  the  users  worked  side  by 
side  with  the  acquisition  community  in 
scheduling,  risk  analysis  and  assessment, 
budgeting,  and  all  other  facets  of  program 
management.  They  received  training  in 
program  management  like  their  acquisi¬ 
tion  corps  counterparts.  They  used 
structured  methods  such  as  quality  func¬ 
tion  deployment  (QFD)  to  trade  require¬ 
ments  not  just  for  performance,  but  across 
a  broad  range  of  acquisition  issues  such 
as  cost,  producibility,  logistics  support- 
ability,  and  development  schedule. 
Requirements  were  rigorously  scrubbed 


by  running  them  through  a  variety  of  mod¬ 
eling  and  simulation  tools  to  validate 
whether  a  requirement  actually  produced 
a  measurable  benefit.  They  motivated  the 
services  to  send  the  best  and  brightest  by 
providing  joint  duty  credit  (a  requirement 
for  flag  officers)  for  those  that  served  in 
the  billets. 

Unfortunately,  this  initiative  cannot  be 
repeated  across  all  programs.  There  are 
not  enough  users  to  assign  them  full  time 
to  every  program  office.  Flowever,  using 
the  Zachman  framework,  some  of  the 
underlying  principles  of  the  successes 
achieved  in  this  pilot  program  should  be 
transferable.  These  include  training  of 
requirements  writers  in  basic  acquisition 
policy,  operational  requirements  docu¬ 
ment  development  through  an  IPT  process 
including  all  stakeholders,  use  of  struc¬ 
tured  methods,  requirements  validation 
through  simulation-based  acquisition 
tools,  and  a  system  that  recruits  the  best 
and  rewards  those  that  perform  well. 
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Implementing  an  Enterprise 
Architecture  in  DoD 


Successful  implementation  of  enter¬ 
prise  architectures  is  difficult  to  accom¬ 
plish  in  any  setting.  Many  efforts  in  the 
commercial  sector  have  failed  for  reasons 
common  to  any  endeavor  to  institute 
change.  These  include  a  lack  of  manage¬ 
ment  acceptance,  failure  to  motivate  per¬ 
sonnel  to  cooperate,  focus  on  short-term 
gains,  political  differences  over  responsi¬ 
bility,  and  lack 
of  resources. 
Implementing 
a  seamless  ac¬ 
quisition  pro¬ 
cess  within 
DoD  will  be 
extremely  dif¬ 
ficult  in  that  it 
directly  con¬ 
flicts  with  the  first  law  of  bureaucracy, 
which  states:  “The  first  priority  of  a 
bureaucracy  is  the  preservation  of  the 
bureaucracy.” 

Much  of  the  increased  efficiency 
achieved  in  the  commercial  sector  has 
been  done  by  targeting  middle  manage¬ 
ment  in  restructuring  and  downsizing.  The 
recent  Government  Accounting  Office 
(GAO,  1996)  report  on  downsizing  shows 
that  government  organizations  have  pro¬ 
tected  managers  while  downsizing  work¬ 
ers.  Industry  has  generally  found  that  the 
use  of  outside  consultants  was  necessary 
to  achieve  a  more  efficient  organization 
when  downsizing.  This  suggests  that 
development  of  a  DoD  enterprise  archi¬ 
tecture  should  be  done  with  the  assistance 
of  outside  consultants. 


Overcoming  resistance  to  change 
should  not  be  underestimated.  The 
commercial  sector  has  also  found  it  diffi¬ 
cult  to  implement  major  changes  to  the 
way  they  do  business.  Implementing 
major  changes  sometimes  requires  devel¬ 
opment  of  a  totally  new  organization. 
General  Motors  created  the  Saturn 
division  because  they  could  not  institute 
the  required  changes  to  automobile 
manufacturing  within  their  union  plant 
structure.  Lucent  Technologies  achieved 
their  threefold  increase  in  growth  after 
being  created  as  a  spinoff  company  of 
AT&T  Corporation.  DoD  has  also  experi¬ 
mented  with  small,  independent  organi¬ 
zations  to  implement  totally  reengineered 
business  processes  in  place  of  large, 
existing  bureaucracies. 

The  Joint  Advanced  Strike  Technology 
Program  (currently  the  Joint  Strike 
Fighter)  was  created  to  operate  outside  the 
Air  System  Commands  of  both  the  Navy 
and  the  Air  Force.  To  date,  it  has  success¬ 
fully  operated  with  a  much  smaller,  leaner 
office  structure  than  comparable  aircraft 
development  programs.  Creation  of  small, 
spinoff  operations  operating  outside  the 
normal  functional  bureaucracies  appears 
to  be  a  successful  method  of  instituting 
reengineered  organizations  at  a  much 
more  rapid  pace  than  incremental  change 
within  large,  established  organizations. 


Conclusions 


Commercial  industries  are  realizing 
that  the  best  opportunities  for  reducing 
costs  are  in  the  architectural  mismatches 
that  exist  within  their  corporations. 


"Successful 
implementation 
of  enterprise 
architectures  is 
difficult  to 
accomplish  in 
any  setting." 
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Realizing  these  cost  savings  will  be  es¬ 
sential  to  survival  in  a  global  economy. 
DoD  must  find  new  ways  to  achieve  the 
cost  savings  necessary  to  replace  the 
numerous  aging  systems  throughout  all 
service  branches.  Development  of  an 
enterprise  architecture  including  seamless 
interfaces  between  each  level,  assignment 
of  responsibilities,  metrics  for  measuring 
success,  and  personal  accountability  for 
results  could  be  a  substantial  contributor 
to  achieving  the  needed  efficiencies  and 
cost  savings.  The  Zachman  framework, 
with  the  addition  of  a  metrics  column, 
provides  the  best  template  for  defining  an 
enterprise  architecture  for  DoD. 


Implementing  the  enterprise  architec¬ 
ture  will  be  the  most  difficult  challenge, 
as  it  will  require  imposing  change  on 
entrenched  bureaucracies.  Transferring 
responsibilities  to  reengineered,  smaller 
organizations  is  one  proven  method  of 
achieving  rapid  change  on  a  large  scale. 
The  question  is  not  if  DoD  will  follow  the 
lead  of  industry,  but  when.  John  Zachman 
(1997,  p.  11)  expressed  it  best  when  he 
said,  “My  opinion  is,  we  are  on  the  verge 
of  seeing  architecture  ‘come  into  its  own,’ 
and  in  the  21st  century,  it  will  be  the 
determining  factor,  the  factor  that  sepa¬ 
rates  the  winners  from  the  losers,  the 
successful  and  the  failures,  the  acquiring 
from  the  acquired,  the  survivors  from  the 
others.” 
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